NASA Contractor Report 166070 


FAULT-TOLERANT SOFTWARE 
FOR THE FTMP 


Herbert Hecht and Myron Hecht 


Prepared for 

THE CHARLES STARK DRAPER LABORATORY, INC. 
Cambridge, Massachusetts 


By 

SoHar Incorporated 
Los Angeles, California 


Final Engineering Report 
Subcontract 564 
Prime Contract NASI -15336 
March 1984 



(NASA-CR- 166070) FAUll-TCLEE ANT SOFTWARE 
FOR THE FIMP Final Report (ScfiaR, Inc.) 

82 p HC A05/HF AO 1 CSCL 09B 


G3/6 2 


N86-24276 


Onclas 
060 31 


Review for general release March, 1986 


COPY CONTROL NO., 


f\J/\SA 

National Aeronautics and 
Space Administration 

Langley Research Center 

Hampton. Virginia 23665 


rvn 4 fcnypfs * ij; F ’ Si I >Z_ 

- v/f- * i: . t . - - =■ 'Vf r ■ 







TABLE OF CONTENTS 


1. Introduction ^ 

1.1. Recovery Blocks 

1 . 2 . Functional Description of the Dispatcher ..6 

1.3. Coverage of the Primary Routine Failures.... ....... 17 

1.4. Software Errors Not Covered By Dispatcher 

Acceptance Tests 

2 . Functional Acceptance Tests... 25 

2 . 1 . Dispatcher Acceptance Tests 27 

2.2. Interval Timer Acceptance Test 37 

2.3. Input/Output Acceptance Tests... ..............40 

2.4. Applications Routines .....43 

3. Structural Acceptance Tests 

3.1. Errors In SLIP and R.DONE 45 

3.2. STUCK IN R4 Acceptance Test.... 

3.3. KICK Acceptance Test and Modifications to KICK 

Procedures 51 

3.4. R4 Responsible Acceptance Test 53 

3.5. Uninterruptible Code Acceptance Test 56 

3.6. Retirement Acceptance Test..................... ,.,.62 

4. Alternate Dispatcher 65 

4.1. Alternate Dispatcher Requirements ......65 

4.2. Description of the Alternate Dispatcher ............ 68 

References 

Appendix A: New Variables Required 71 

Appendix B: Uninterruptible ASM routines . ....73 


i 



List of Figures 


EJautfi utu fags 

1.1 Implementation of the Recovery Block for the FTMP 4 

1.2. R4 Frame Initiation — Interrupting R3 and R1 8 

1.3. R4 Frame Termination — Resume R3 jq 

1.4. R4 Task Invocation Procedure Control Flow 12 

1.5. R3 and R1 Task Invocation Procedure Control Flow 13 

1.6. Pend and Activate Handling ^5 

1.7. Interrupt Hand 1 1 ng 16 

1.8. Top Level Fault Tree for the FTMP Dispatcher 18 

1.9. Initialization Faults 20 

1.10. Execution Order Failures 21 

1.11. Timing Failures 22 

1.12. Recovery Block Faults 23 

2.1. Sequence of Timer Interrupts and Dispatcher Acceptance Tests 26 

2.2. Fault Tolerant Provisions for the FTMP Dispatcher 30 

2.3. Dispatcher Critical Word Acceptance Test Module 31 

2.4. Frame Count Acceptance Test Module 33 

2.5. Frame Counters ^5 

2.6. Critical Word Reset Acceptance Test Module 36 

2.7. Interval Timer Acceptance Test 39 


PRECEDING PAGE BLANK NOT FILMED 


iii 

vmLNTlONALUt 8-^ 


List of Figures (continued) 


EJqure 

Title 


Page 

3.1. 

SLIP Acceptance Test 


47 

3.2. 

R.DONE Acceptance Test 


47 

3.3. 

STUCK. IN. R4 Acceptance Test 


50 

3.4. 

KICK Acceptance Test 


50 

3.5. 

R4. RESPONSIBLE Acceptance Test 


55 

3.6. 

Uninterruptible Code Acceptance Tests 

Triad Working 

59 

3.7. 

Uninterruptible Code Acceptance Test: 

Triad Idling 

61 

3.8. 

Retirement Acceptance Test 


64 

4.1. 

Alternate Dispatcher 


69 


iv 


This Is the Final Engineering Report prepared for The Charles Stark Draper 
Laboratory, Inc. under Subcontract 564 (Prime Contract NAS 1-1 5336), covering 
technical assistance In fault tolerant software development for the Fault 
Tolerant Multiprocessor (FTMP) . This report satisfies Item 4.5 of the 
subcontract. 

The FTMP Is a highly reliable computer Intended to service reliability-critical 
applications In scheduled aircraft service. Work on the architecture to provide 
the required hardware fault-tolerance has been In progress since the 
mld-slxtles, and has evolved Into a well-understood highly redundant system 
described In ref. 1. Although this design effectively addresses the detection, 
masking, and elimination of hardware faults. It can not circumvent failures due 
to software faults. 

The work reported on here provides protection against software failures In the 
dispatcher of the FTMP, a particularly critical portion of the system software. 
Faults In other system modules and In application programs can be handled by 
slm lar techniques but coverage for these was not provided In this effort. 
Goa s of the work reported on here are (1) to develop provisions In the software 
design that will detect and mitigate software failures In the dispatcher portion 
of the system executive and (2) to propose the Implementation of specific 
software reliability measures In other parts of the system. In proceed I nq 
Toward These goals. The following consTralnTs were observed: 

the coverage of the dispatcher was to be complete; no potential failure 

modes were to be overlooked due to difficulty of Implementation, and 

the additional software required for Implentatlon of fault tolerance was to 

be simple, to minimally affect the design and the operation of the current 

system, and to minimize the Introduction of new variables. 

All of these requirements have been met by the design described In later 
sections of this report, and a basis has therefore been provided for augmenting 
the hardware fault tolerance provisions of the FTMP with equally effective 
measures for sofTware fauIT Tolerance. 

Beyond the specific support to the FTMP project, the work reported on here 
represents a considerable advance In the practical application of the recovery 
block meThodoiogy for fauIT ToleranT sofTware design. The operaTIons carried 
out by the dispatcher are primarily In the area of logic and sequencing, and 
error detection techniques for such operations are more difficult than for 
programs dealing with flight data for which reasonableness tests based of 
physical constraints can be devised. The acceptance tests for dispatcher 
functions had to be based on logic that was Independent of the logic used In the 
primary program. 

In pursuing the goal of Independent acceptance tests. It was found convenient to 
divide these Into two classes: functional acceptance tests which determine 
comp | lance with program requirements, and structural acceptance tests which 
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determine adherence to a predefined logic flow. These tests, as devised for the 
FTMP, are described In Sections 2 and 3, respectively, and they represent an 
Implementation for a particularly challenging environment. When these tests are 
not satisfied, the program either retries or Invokes an alternate dispatcher 
directly. The design for the latter, described In Section 4, Is entirely 
Independent of that of the primary dispatcher. Both the hardware and software 
structure Is less flexible (and therefore less efficient) but correspondingly 
more rugged. Because most software failures are not permanent, the alternate 
dispatcher will attempt reversion to the primary one at discrete Intetvals 
during routine operation. In this way, the reduced efflcency of the alternate 
will In most cases have very little effect on the operation of the flight 
programs. 

Before leaving this part of the Introduction, the authors wish to express their 
thanks for the cooperation received In this effort from personnel of The Charles 
Stark Draper Laboratory and of the NASA Langley Research Center. Dr. Albert L. 
Hopkins gave whole-hearted support to this work and made many helpful 
suggestions. Drs. Basil T. Smith and Jay Lai a facilitated the design of the 
fault tolerant software by making the design and data for the primary dispatcher 
available and patiently explaining details when this was required. To Mr. Billy 
L. Dove and Mr. Nicholas D. Murray our thanks for the support of this work and 
for permitting us to participate In an Important area of fault tolerant 
computing. 
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1.1. RECOVERY BLOCKS 


The Inability to perform conclusive reliability evaluations on software 
motivates the development of fault-tolerance techniques. Two techniques for 
achieving fault-tolerance have been discussed In the recent literature: the 

recovery block and N-verslon programming. N-versIon programming Involves a 
number (at least two) of Independently coded programs for a given function that 
are run simultaneously (or nearly so) on loosely coupled computers. The results 
are compared, and In case of a disagreement, a preferred result Is Identified by 
a majority vote (for three or more versions) or a predetermined strategy. 

The second technique, and the one used In the FTMP, Is the recovery block (refs. 
2 and 3). The simplest structure for the recovery block Is 

Ensure T 


By P 

Else by Q 
Else Error 

where T Is an acceptance test condition, l.e. a condition which Is expected to 
be met by successful execution of a primary routine, P, or the alternate routine 
Q. The Internal control structure of the recovery block will transfer to Q when 
the test conditions are not met by executing P. 

Implementation of recovery blocks for the FTMP Is shown In fig. 1. The primary 
routine Is executed, and If the acceptance test conditions are not met, the 
alternate routine Is Invoked. The number of passes through the alternate 
routine Is counted, and after a predetermined limit (dependent on the 
capabilities of the primary and alternate programs, execution time, and other 
factors), a transition Is made back to the primary routine. 

The key element of the recovery block approach Is the acceptance test. There are 
two levels on which acceptance tests can be performed. The first Is the 
functional level, l.e. that which tests that the outputs of the program are 
consistent with the functional requirements. The second Is the structural 
level, which tests sections of code to ensure that key variables and functions 
have been properly executed. Functional level tests are appropriate for software 
that has been in use a long time because they are simpler and It avoids 
unnecessary transfers. However, for programs under development, the addition of 
structural tests provide the following benefits: 

1. Unexpected behavior of the primary systems will be noted even In 
cases where only a mild degradation Is encountered. This aids 
In program evaluation. 
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FIGURE 1.1 Implementation of the Recovery Block for the FTMP 
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2. Switching to the alternate program Is exercised more often under 
realistic (unplanned) conditions. Providing realistic testing of the 
fault tolerance mechanism Is a difficult undertaking. 

3. As a program matures. It Is usually easier to relax acceptance 
conditions than to make them more restrictive. 
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1*2. FUNCTIONAL DESCRIPTION OF THE DISPATCHER 


The FTMP task dispatching function selects an applications routine for an 
available processor, relinquishes control of the processor for a set period to 
enable task execution, and then returns to select the next task or pass control 
to a lower priority executive process. By vlrture of Its multiprocessor 
arrangement, the execution order of tasks Is not fixed, and thus, the dispatcher 
must perform the following functions: (1) determine how frequently a task should 
be run, (2) determine whether data and predecessor tasks have been completed, 
(3) Invoke the task and enable Interrupts for higher priority Items or overtime, 
and (4) maintain records of functions which have been executed along with other 
housekeeping tasks. The centrality of this function to the FTMP operation made 
It a prime candidate for the Implementation of software fau I t— tol erance 
measures. 

Because the scope of the Implementation of fault-tolerance was limited to the 
dispatcher and associated routines, the design of acceptance tests and of the 
alternate dispatcher was based on a portion of the entire system executive. 
This section presents the functional specifications of relevant portions of the 
FTMP operating system upon which this report rests. 

The dispatcher Is divided Into two major routines: the R4 rate group 
dispatcher, designated as R4 . D I SPATCHER, and the R3 and R1 rate groups 
dispatcher, designated as R3.R1 .D I SPATCHER. The R4 dispatcher performs five 
major functions: 

1. Initialization during system start up 

2. R4 frame Initiation 

3. Reading error latches and performing I/O to the 1553 bus 

4. Task selection and execution 

5 . Ret I rement 

The R3.R1 .DISPATCHER relies on the R4 dispatcher for the above functions, and 
thus. It only performs task selection and execution for the appropriate rate 
groups. Section 1.2.1 contains a more detailed description of the means by 
which the dispatcher routine performs these functions. 

A crucial requirement of the dispatcher Is that It perform Its functions within 
strict timing limits. Thus, a number of routines external to the dispatcher are 
necessary to maintain the proper time references and to perform Interruptions at 
appropriate Intervals. These routines are discussed In section 1.2.2. 
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1.2.1. Dispatcher functions 


initial Izatlon 

Initialization consists of restoring portions of the system memory to default 
values and zeroing out other portions. Initialization Is entered upon a restart 
flag being set to TRUE, and results In the following: 

The triad to start Initialization becomes R4. RESPONSIBLE 
The system timer Is Initialized 
Triad busy states are set to free 

Triad status words are set to enable execution of all rate groups 

Reconfiguration commands and states are set to 0 

The configuration controller Is Initialized 

Unlock and I PC Interrupt commands are set to 0 

Error latches are cleared 

The rate group control blocks for all dispatchers are tnltallzed 
Lower rate groups are set to be executed In later frames 

R4. frame Initiation 

A new R4 frame is started every 40 msec. At the start of a new frame, the R4 
dispatcher takes the following actions: 

lower rate groups are Interrupted and their timers are stopped 
the triad states are updated 

task pointers are set to begin at the top of the R4 list 

lower rate groups are pended for execution at the appropriated frames 

I/O for the appropriate rate groups Is performed 

error latches are read and cleared 

reconfiguration occurs If any commands are pending 

The start of a new R4 frame takes precedence over all other actions. FTMP 
senses the start of a new time frame when a triad responsible for the frame 
restart, designated as R4. RESPONSIBLE, responds to a timer Interrupt. Figure 
1.2, adopted from a CSDL briefing chart, shows the sequence of events after the 
R4 Interrupt. The R4 responsible triad, shown In the center. Is the only one 
whose timer Is set with the new frame time. After It performs the 
Initialization, It sends an Interprocessor CIPC) Interrupt to a second triad, 
which Is shown as being In the Idle mode. This second triad then starts up the 
R4 dispatcher for Itself, and sends an I PC Interrupt to the third triad shown 
executing the R1 rate group. The third triad will Interrupt execution of the 
current process, freeze the timers and other relevant control variables, and 
restart the R4 dispatcher. 

Iflsk -SeJect Ion and execution 

After completion of the R4 frame Initialization tasks, the R4 dispatcher enters 
a task selection loop using an Internal procedure SELECT. TASK. All tasks to be 
executed In the R4 rate group are contained In a list. Elements of this list, 
denoted as task control blocks (TCBs), contain Information on proceeding and 
succeeding tasks, time limit, and most recent execution. Additional pointer 
variables lead to data buffers for I/O for each applications task and to 
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2nd R4 appl Icatlons routine 
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Interrupting R3 and R| 



constraints, l.e. tasks which must be executed prior to the current one. 

IreL e from + ih« hnJ# rS ? V m !f nS °l a ? ,n+ernal Procedure EXECUTE which reads data 
+r?»H k +h buffer locations designated by the TCBs from main memory Into the 
triad cache memory, starts the R4 timer, and passes control to the task by means 

contro| SM wM < ? C h dUre ACT !/h TE l +' f +h ® +aSk h8S n0+ run over l+s +,me ^ Iml+, 
frar^count n th^^L^ + ° EXECUTE Upon ,+s com P ,e+I °" "Mch updates th^ 
< flsl cZlllnoT +S 8PPrOPr,0te b,t ,n tho “"Str.ut »or<i to 

SELEC^T^rfinHt'rn^!^. 100 /^ execu+fo " continues In this manner until 

trlatTnotes +h2+ +h. + Z* U , e + f< T V 5UCCeed,n 9 +ask pointer. At this point the 
d n o+es that the task list Is done In system memory and sets Itself as 

responsible for starting the next R4 frame, updates the R4 task list In main 

memory, and restarts timers and lower rate groups which were Interrupted at the 

beginning of the current frame. Figure 1.3, also adopted from a CSDL briefing, 

lStIrrn^+AH e+ ^ n JVJ® sys+ f m +0 1 ower ra+e group tasks. If no tasks were 
Interrupted, the triad goes to an Idle process until the next Interrupt. 

Ret I rement 

IL e fi r«+ l lH , k fU rk C+,0n < ? f +h J e , R4 dls P a+ cher Is to recognize the retire command 
generated by the configuration controller. Retirement means that a triad has 
sustelned a permanent failure and will no longer be able to execute tasks. 
Retirement Involves setting the following variables: 

triad status bit to prohibit execution of the R4 rate group 
setting the triad busy word to Indicate this triad Is not worklnq 
decrementing the R4 triad counter 
Initiating the Idle process 

i'n :^: a+ I r ! n 2 ! r,ad , Is ? ,so ^-RESPONSIBLE, It must restart the R4 dispatcher 
In another triad In order to provide another triad with the responsibility of 

setting the time to and starting the next frame. The means of performing this 
change Is a higher priority IPC Interrupt, which will cause the receiving triad 
to halt execution of Its previous task until the Interrupt Is handled. 

Lc wer rate group dispatchers 

Ik 6 an J? ra+e 9 rou P s have +as k selection and execution functions similar to 
In.??,?. f t OUP ' bU » + ar 5 "?! responsible for restart, I/O, retirement, or 
I n I + I a I I z a+ 1 on . An additional function of the lower rate groups Is the 
e ecrlon of a need to continue execution of their applications routines beyond 
the time allowed In the current frame. Should the task list complete markers 
for the lower rate groups not be set to TRUE, a variable designated as SLIP will 
be decremented. The decrementing of SLIP will, when added to the frame count, 
have the effect of delaying the restart of the R3 rate group by one frame, and 
the R1 rate group by two frames. 


1.2.2. Timing routines associated with the Dispatchers 


9 


iple+ed Its 
task, could 


U3 

I J 

- <r n — < Q 

j ps a: oc; 


C X? 

o cn 

«JQ£ 

* T? 

C -"O 
— tfl Q) 

'i- L. E 

® =3 C 
E 4- -C £ 0 
5^ O 4- <D 7 - 

O QT C O L. 4- 


© co 

£ TI — 
4- C CO 

<0 z 
x» O 

© ^ CL 
4- trt © co 
O (0 e LU 
<D +* C 
— o . 

<D © Tt 

w a: x> a: 


E 


FIGURE 1.3. R4 Frame Termination — Resume R3 


Figures 1.4 and 1.5 show the sequence of execution of various procedures 
associated with the R4 and lower rate group dispatchers respectively. Those 
associated with timing are underlined. As Is evident from both figures, triads 
act on the basis of time-generated Interrupts. The time to the Interrupts Is 
P eced In a register denoted as the INTERVAL TIMER and decremented at 250 
microsecond Intervals until It reaches zero. At this point a timer interrupt Is 
generated. 


At the beginning of a new frame, the R4 rate group dispatcher will save the 
times left for interrupted lower rate group executions by means of the 
HOLD. R3.R1 .TIMERS routine. As shown In figure 1.4, the R4 dispatcher causes the 
activation of the lower rate groups by pointing to the addresses of their 
process state descriptors (figure 1.6) at the appropriate frames. After 
completing frame Initialization, the dispatchers Invoke applications routines by 
means of the SELECT and EXECUTE procedures described above. Prior to passing 
control to the applications routine, the dispatcher starts a timer which will 
Interrupt execution should the applications routine run over the time limit 
written in Its task control block. If an Interrupt occurs, a routine designated 
+ S t h ® J ^ I NTERRUPT. HANDLER Is executed. This procedure determines whether a 
task time-out or a new frame Interrupt occurred (If the triad Is R4 
responsible), and sets up the R4 dispatcher to be restarted In the latter case. 
In the absence of an Interrupt, the dispatcher repeats the process with 
subsequent applications routines until the list is complete. 


Upon completion of the R4 Iteration, the timers of the lower rate groups are 
restarted by the RELEASE. R3.R1 .TIMERS procedure, and control Is passed to the R3 
dispatcher by means of a RESUME statement and the PEND procedure executed at the 
beginning of the frame. The R1 timer Is saved by means of the HOLD. R1 .TIMER 
routine, and the R3 rate group applications routines are selected, executed, and 

Tk dt U t d ,f necessar y ) ,n +he same manner as were the R4 applications tasks. 
The R3 .TIMER routines are somewhat more complicated because the times they place 
In the nterval timers must also observe the total frame time limit, l.e. If the 
time allowed for an applications routine Is greater than the time remalnlnq In 
the frame, the Interval timer Is. set with the time remaining in the frame. 

Upon completion of the R3 dispatcher In a frame where R1 Is to be run, the R1 
rate group timer Is released and the R1 dispatcher Is invoked as described 
above. Execution of the R1 rate group dispatcher and applications routines Is 
Identical to the R3 execution with the single exception of R1 timer routines 
rather than R3 timer routines used for starting and stopping the Interval timer. 
Because no rate groups are executed behind R1, there Is no need to hold or 
release other timers. 


1.2.3. Execution Order 


Each resident process within the triad has a process state descriptor (PSD) 
resident In the cache memory which contains a pointer to the location of the PSD 
for a succeeding task. In this manner, a number of tasks can be arranged to 
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Figure 1.4. R4 task Invocation and procedure control 















FIGURE 1.5. R3 and R1 Task Invocation Procedure Control Flow 







execute in consecutive order. Changes to this order are implemented by the 

PEND and ACTIVATE routines as depicted in figure 1.6 (adopted from a CSDL 

briefing chart). Process X is currently being executed by the triad, and is 
designated as the active process. A PEND(A) command will cause process A to 
be inserted in the task execution order as shown In the second column in 
figure 1.6. The ACTIVATE(B) command will immediately transfer control to the 
process B as shown in the third column of figure 1.6; the previously active 
process continues at the conclusion of process B. 

The response to interrupts is depicted in figure 1.7, adopted from a CSDL 

briefing chart. Prior to the Interrupt, a process denoted as Z is active in 

the triad, as shown by the "AP" marker. After the interrupt occurs, the 
address of the process Z PSD is saved In a location of the interrupting 
process PSD, and the interrupting process becomes active. At the conclusion 
of the interruption, a RESUME command Is executed, and the PSD of process Z 
becomes active once again. 
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FIGURE 1.6. Pend and Activate Handling 



















1.3. COVERAGE OF THE PRIMARY ROUTINE FAILURES 


faTlur^ 0 5l!? n Ti +he .J es l9 n °{ acceptance tests are based on the potential 
f al lures derived from the description of the dispatcher and associated routines 

anU I +? C+I °" I* 2 - l+ " as f °u"d +hat fault trees aided the systematizing 

art ° n + Kl ^ ce P +ance +“+ development, and therefore, these trees 

are presented fn this section. 

Figure 1.8 Is the top-level fault tree which shows that failure of any of the 

funr+i^oV+K 5 * ,+h 8,1 rate group dispatchers (l.e. the five 

dl7nJ+rL?) In, dI fP a |cher and the task dispatching function of the R3.R1 
ffri+ + +k h r ![V i result n a failure of the entire dispatcher. Failures of the 
+k + t Qe / aU + ca+ egorIes are expanded In subsequent diagrams referred to In 
the triangles under the event Identifications. Failures In reconfiguration and 

C ° + V6red r ?.! h,S work * The numbers 9 lven In the circles below these 
de^r Ibed 6 * eP + ° Spec f c sec+Jon numbers where the relevant acceptance test Is 


The reader should note that any input to an "0R H gate causes its output to be 

nil 1 !;;* I I*, 1 ? order for an out P ut fau1t g iven at the top of an OR gate to be 

detected, all inputs must be detected. However, in the case of an "AND" qate 

a I inputs must be true in order for the output to be true, and thus onlv a 

single fault need be detected in order to assure coverage. y 


Initial Izatlon Faults 

A further development of initialization failures is contained in figure 1 9 

Two initialization failures would result in dispatcher error conditions 

failure to set the triad as R4 Responsible and failure to properly initialize 
the rate group control blocks. H y initialize 

rtn C nn+ e „! +her f M C+ !° n ! ! Is+ed In sec+,on 1 * 2 * 1 under frame count Initialization 
do not necessarily lead to critical failures, the are not considered explicitly 

In a portion of the possible range. Initialization failures will result In 

be 9 dlsabled ,S "S* suff,c,en+| V critical to cause the function to 

f!hirh d h ?J ce ' does no+ warrran+ Invocation of the alternate dispatcher 

(which tself provides degraded performance relative to the fully functional 

i he f0 | ,0 * ,n 9 functions were deemed to be In this category under some 
conditions In restart Initialization: 


resetting of error latches, triad busy states, and triad statuses 
Initialization of the timer 

lower rate groups set to be executed In later frames 
reconfiguration states are set to 0 
UNLOCK and I PC Interrupts are set to 0 


in conamons more 


Other possible Initialization errors could result 

than degraded performance. For example. If all triads are set to busy 

tk! ,i+? r ® s+ar+ + be R4 processor, then there will be no R4 responsible triad. 

dlsn«+rhorc te a reSU il+? f +h ?? e errors ,s +he Improper execution of the rate group 
dispatchers, a condition which Is covered by acceptance tests, and hence, no 


3^1 I VUd 

and are 
triad. 
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FIGURE 1.8. Top Level FojI+ Tree for the FTMP Dispatcher 









additional provisions are necessary. 

T?J.* f ® ,,u ^ e class '" c,udes errors In frame Initiation which causes lower rate 
group dispatchers not to be Invoked at appropriate Intervals and errors In task 

^tI C nLL 0 2t a r«| eXeCUt ! 0n Wh,Ch reSUl+ ,n fa,,ure + ° dIs P atch all applications 
routines of a given rate group. rr 

AMMr. 1 +V«nf h ?'ti ( the fU r! her , develo P men+ of possible failures In this category. 
Applications tasks could either be omitted, or they could be executed 9 too 

accentanrV tA + 0 m i SS °l cr, + ,cal +asks are detected by the functional 
fluent «v«rt + 1 f sec J , ? n 2 > and +he setting of variables which result In too 
section 3 X0CU+,ons of +asks are covered by the structural acceptance tests of 

XJ mlng Fa I lures 

Failures of the functions described In section 1.2.2 are Included In this 
category. The most apparent source of failures Is the hardware clock, which Is 
adequately covered by quadruple redundancy, hardware voting, and spares, and 
which need not be protected by additional software provisions. 

A second cause of failures is the R4 rate group being "stuck", a condition which 
occurs under the three circumstances shown in figure 1.11. The first circum- 
stance, being stuck in an R4 applications routine is handled by the interval 
timer acceptance test described in section 2. The second, R4 stuck in task 
selection group and the third uninterruptible ASM sequence, are covered bv a 
single acceptance test described in section 3. 

-L/Q and Retiremen t Failures 

Because the I/O protocols were not described In detail In ref. 4, It was not 
possible to devise a set of acceptance tests to provide definitive coverage. 

£ he I1 r , ela t , y ely P° werful "*rap around" acceptance test described In 
section 2.5 will aid In covering this failure, and based on final design of the 

J .. ^ rC i j e< ^ UreS ? ? an * 5e * ncor P°rated with supporting structural acceptance tests 
to provide complete coverage. 

The reconfiguration strategies have been developed and documented elsewhere, and 
do not fa | under the scope of the dispatcher. However, once the retirement 
command Is given, the dispatcher is responsible for carrying It out. Section 
o.o describes the retirement acceptance test. 

E osslble Failures Introduc e d by Recovery RlnH^ 

Figure 1.12 Is a fault tree showing the possible failures Introduced by the 
recovery block structure for the dispatcher. As Is shown, failures can be Y due 
to a pr rnary routine failure coupled with a fault In either the acceptance test 
or the a,+ ®rnate routine as well as a type II error (l.e. false Indication of 
failure) by the acceptance test and failure of the alternate routine. Coveraqe 
of acceptance test failures Is handled by both the critical word reset 
acceptance test, which ensures that a proper critical word mask Is used by the 
dispatcher acceptance test, and the frame count acceptance test, which ensures 
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FIGURE 1.12. Recovery Block Faults 












that the dispatcher uses the proper frame when testing for „the execution of the 
R1 and R3 rate groups. 
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1.4. SOFTWARE ERRORS NOT COVERED BY THE DISPATCHER ACCEPTANCE TESTS 


'The scope of both the functional and structural acceptance tests has been 
P+n thp failures of the dispatcher and supporting routines, AED 
;;:«dures%ot covered by S the accepted 'tests Include LOCK/UNLOCK, IPC. INTERRUPT, 
and the reconfiguration tasks. 


■SECTION 2 - FU NCTIONA L ACCEPTANCE TESTS 


As noted In section 1.1, functional acceptance tests are those which test the 
output of a software module for the achievement of a functional objective. Such 
tests have been developed for the dispatcher, routines setting -Hie Interval 
timer, and functions associated with I/O . ' 

* S 

The dispatcher acceptance test checks memory locations In which critical tasks 
from each rate group have set bits In the course of their execution. If the 
words Indicate that all crltfcal tasks In the given frame have been run, the 
dispatcher acceptance test resets the critical words for the next frame. Two 
additional routines that are associated with this acceptance test check both the 
Input frame count and the output reset critical words. Details of the dlsptcher 
acceptance test are described In section 2.1. 

The Interval timer acceptance test checks the Interval timer after the execution 
of any routine which can affect the timer value. If the time Is less than that 
of the current frame, a normal exit occurs. Details of the Interval timer 
acceptance test are described In section 2.1. 

The I/O acceptance test checks an Independent counter showing the number of 
times the buffer has been accessed and compares It with the frame count. 
Without a detailed knowledge of the final I/O protocols used for the FTMP, It 
can not be concluded that this acceptance test provides a definitive 
determination of normal execution, but It Is anticipated that It will be useful, 
especially If combined with additional specific structural acceptance tests* 
Details of the I/O acceptance test are described In section 2.1. 

Finally, although not defined specifically, each critical applications routine 
will have Its own functional acceptance test which checks the vallldtty of Its 
Input and output. Tests for determining whether constraints have been met for 
the running of applications routines Is also part of the function of these 
acceptance tests. 


INTERRUPT 
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FIGURE 2.1. Sequence of Timer Interrupts and Dispatcher Acceptance Tests 
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2.1. DISPATCHER ACCEPTANCE TESTS 


As noted above, the overall dispatcher acceptance test scheme consists of 
checking the values of critical words which Indicate that ta£ks crucial to 
maintaining stable flight conditions have been run In each rate group. However, 
because the critical task group varies as a function of the frame count, a 
second test must ensure that the dispatcher uses a proper value for this 
variable. Finally, the critical words must be reset at the beginning of. every 
frame; the successful execution of this function ts verified by a third 
acceptance test. Thus,, a totbl of three modules for tho acceptance tests 
associated with the dispatcher have been developed: 


l5i>JLJ^lL£.aJXuce.,of^eJJsp_a±^x J . The overal I functional tests for the 
dispatcher I sto determine whether all critical tasks within a given rate 
group have bpfen executed at the appropriate times. Failures of a dumber 
of functions are detected by this test. This test Is further described In 
section £.1 *1 • 

Xcs_t — lo r_ E a LLune_ oi — i iie__F r ,aine__C Oil iriien.. Failure of the frame counter can 
result In the Improper timing for execution of lower rate groups. If the 
counter Is not Incremented or Is Incremented by greater than one. It Is 
possible that lower rate groups will not execute at all. The test for 
proper Incrementing of the frame counter Is described In section 2.1.2. 

iXltL£gi3^rdJese±^ccmtQnce_Je5±. Failure to reset the critical word 
can result In Improper assessment of whether the rate groups have been 
completed. At the conclusion of the dispatcher acceptance test, the 
critical word Is compared with Its Initial value stored In memory. If 
these values do not agree, then the alternate schedu I er-d I spatcher Is 
Invoked. This test Is further described In section 2.1.3. 

The point In the frame at which these tests are executed Is shown In figure 2.1. 
After the R4.RESP0NS IBLE triad receives an Interrupt signaling the beginning of 
a new frame, the acceptance tests are Invoked, and the R4 dispatcher Is 
restarted. 


2.1.1. Dispatcher Critical Word Acceptance Test 


The specification of the dispatcher requires that all R4 tasks will be completed 
every frame, all R3 tasks every second frame, and all R1 tasks every eighth 
frame. The acceptance test will rely on the existing clock and frame count to 
verify that this functional requirement Is met.. However, an Independent 
acceptance test will verify the frame count by means of two Independent counters 
(see sec. 2.1.2). The acceptance test will check a critical word for the 
appropriate rate group. If this word Indicates that all tasks have been 
completed (by being set to all 1's), then It will reset the word (In a manner 
that will also be f au I t-tol erant, see sec. 2.1.3) and proceed to test the next 
lower rate group as appropriate. If a discrepancy In the critical word Is 
detected, the acceptance test will Invoke the alternate dlspafcher. 
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Figure 2.2 shows the dispatcher and accompanying fault tolerant provisions 
(this configuration is the same for all rate groups) invoked at the beginning 
of a new frame. If the dispatcher acceptance test Is sottsf actory, , the primary 
dispatcher Is re-executed as shown In the left-hand branch of figure 2 . 2 , and If 
not, the alternate dispatcher Is executed. Critical appl Icatl on's, routines will 
set appropriate bits In the critical word for that rate group. 

Figure 2.3 Is the Nassl-Schnetdeman diagram of the dispatcher acceptance test 
and table 2.1 shows the requirements. As each rate group critical word; Is 
tested. It Is reset, and the reset function In turn Is tested (setion 2.1.3). 
If any rate group critical word Is not satisfactory, the alternate dispatcher Is 
Invoked. i 


2.1.2. Frame Count Acceptance Test Requirements 


The frame count acceptance test Independently verifies that the frame counter 
has been properly Incremented. It Is Invoked prior to execution of the 
dispatcher as shown In figure 2.1. Figure 2.4 Is an Nassl-Schne I deman diagram 
for this acceptance test. As shown In figure 2.5, two Independent frame 
counters, NEW. FRAME and OLD. FRAME (each counting from 0 to 15) In this 
acceptance test are used to ensure that proper Incrementing has been carried out 
within the test. A comparison Is then made with the dispatcher frame counting 
variable FRAME. COUNT. If a discrepancy Is found, all frame counts are restarted 
at 0 without the need for the alternate schedu I er-d I spatcher . However, If a 
discrepancy persists for an arbitrary number of consecutive times (we have 
chosen three consecutive times), then the acceptance test Invokes the alternate 
scheduler-dispatcher. The requirements for the frame count acceptance test are 
given In tabl e 2.2 


2.1.3. The Word Reset Acceptance Test 


If the critical words are not properly reset, the dispatcher critical word 
acceptance test may fall to detect that the dispatcher has not Invoked all 
appl Icatlons tasks. Most likely, the failure of the critical word reset will 
result In the final word (at the end of the frame) Indicating that all critical 
tasks have not been completed when they all have actual ly been run. However, 
there Is also the possibility that the critical word Is not properly reset and 
that the tasks are notcomp I etel y executed. The dispatcher critical word 
acceptance test will then Indicated proper completion even though this has not 
been achieved. 

The requirements proposed for the word reset acceptance test are given In table 

2.3, and figure 2.6 shows the Nassl-Schne! deman diagram. 
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TABLE 2.1. Dispatcher Critical Word Acceptance Test Requirements 


1. The dispatcher critical word acceptance test checks rate group critical 
words at the beginnings of the appropriate frames after the frame count 
has been verified by an Independent acceptance test. ' 


a. The R4 critical word Is checked at the beginning of every frame. 

b. The R3 critical word Is-checked at the beginning of even frames 
(l.e. 0, 2, 4, 6, 8, .10, 12, and 14). 

c. The R1 critical word Is checked at the beginning of frame 0 and 8. 


2. If the rate group critical word Is correct, the dispatcher acceptance test 
will reset It. A separate acceptance test verifies Its re-lnltlal Izalon 


3. If the rate group critical word Is not correct, the dispatcher acceptance 
test will Invoke the alternate schedul er/dlspatcher. 



FIGURE 2.2. Fault Tolerant Provisions for the FTMP Dispatcher 
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FIGURE 2.3. Dispatcher Critical Word Acceptance Test Module 


31 



. V 
« 

TABLE 2.2. Frame Counf Acceptance Test Requirements 

» » 

I 

1# The frame count acceptance test will be Invoked every frame as an R4 
critical appl Icatlons routl ne. 

a. The frame count acceptance test will set a bit In the R4 critical word* 

„ * • V, 

b. The dispatcher critical word acceptance test will check the R4 critical 

word to verify that this acceptance test has been run In the previous 
frame. .. 


2. The frame count acceptance test will Increment Its own Independent frame 
counter, and then ensure that It has been properly Incremented. 

a. The acceptance test frame counter, NEW. FRAME, will be Incremented In the 
range 0 to 15 (by using NEW. FRAME modulo 16). 

b. The difference between NEW. FRAME and a second acceptance test counter, 
OLD. FRAME will be checked. 

If the difference Is 1, then OLD. FRAME Is set equal to NEW. FRAME 
(l.e. NEW. FRAME Is properly Incremented) 

If the difference Is not equal to 1, the NEW. FRAME, OLD. FRAME, 
and FRAME. COUNT (the primary dispatcher frame counter) are set 
to 15 so that tasks for all three rate groups will be executed 
In the subsequent frame. An error counter, FRAME. FAIL. COUNTER, 

Is Incremented and checked to see that It has not reached a prese + 
limit (3 Is chosen at present). If FRAME. FAIL. COUNTER has 
exceeded the limit, then the alternate scheduler-dispatcher 
Is called. If It has not, then the primary dispatcher Is 
Invoked at the new frame count. 


3. If the acceptance test frame counter has been properly Incremented, It ’ 

Is compared to the primary frame counter. 

a. If the acceptance test frame counter and the primary frame counter 
agree, FRAME. FAIL. COUNTER Is set to zero and the primary dispatcher Is 
I nvoked . 

b. If the primary frame counter and the acceptance test frame counter do 
not agree, NEW. FRAME, OLD. FRAME, AND FRAME. COUNT are set to 15 so that 
all three rate groups will be executed In the subsequent frame. 

FRAME. FAIL. COUNTER Is Incremented and checked to see that It has not 
reached a preset limit (3 Is choen at present). If FRAME. FAIL. COUNTER 
has exceed the limit, then the alternate dispatcher Is called. If It 
has not, then the primary dlsptcher Is Invoked at the new frame count. 
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FIGURE 2.4. Frame Count Acceptance Test Module 
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TABLE 2.3. Critical Word Reset Acceptance Test Requirements 


1. The critical word reset test Is called by the dispatcher acceptance 
test. 

2. The memory location containing the rate group critical word which has 
just been reset Is compared with the memory location containing the 
Initial value to which the word should have been changed. 

3. If these values agree, normal execution of the primary dispatcher Is 
continued. 

4. If these values do not agree, then the alternate dispatcher Is Invoked. 
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2.2. INTERVAL TIMER ACCEPTANCE TEST 


The Interval timer Is the crucial system component which ensures that Interrupts 
occur at the proper Interval. A total of ten AED procedures control and arm the 
Interval timer: 


H0LD.R3.R1 .TIMERS 
HOLD. R1 .TIMERS 
RELEASE. R3.R1 .TIFCRS 
RELEASE. R1 .TIMER 
START. R4. TIMER 
START. R3. TIMER 
START. R1 .TIMER 
STOP. R4. TIMER 
STOP. R3. TIMER 
STOP. R1 .TIMER 

Each of these procedures must determine the time to the next Interrupt, the type 
°* '*yerrupt, load the Interval timer register with the appropriate value, and 
arm It. Failure to load, arm, or properly Identify the next Interrupt will not 
be detected by any of the previously defined acceptance tests. 

A means of detecting these failures Is therefore Included as an additional 
functional acceptance test. This test, designated as the Interval Timer 
Acceptance Test, ensures that the value In the Interval timer of the R4 
responsible triad Is less than the value to the next R4 frame as defined by the 
different between R4. TICK. TIME and TIME. NOW. If the Interval Is greater than 
the difference, or If TIME. NOW Is greater the R4. TICK. TIME, then a functional 
error has occurred In one of the timer routines, and the alternate dispatcher Is 
Invoked. Table 2.4 lists the requirements for the Interval Timer Acceptance 
test, and figure 2.7 Is the Nassl-Schne! deman diagram for this procedure. 

The reader should note that this test will not affect the values of non-R4 
responsible timers. These Intervals continue to extend beyond the next R4 

frame, and can not be used as back-ups to ensure the timely start of the R4 
frame. 

i v 

Although the acceptance test does not check for the occurrence of the 
appropriate Interrupt or that R4. TICK. TIME has been set to a new value 
explicitly. It does so Implicitly through the condition Identified In 4b of 
table 2.4. If an Interrupt other than that for a new frame has been set at the 
J f Yt erru P+ time, then the acceptance test will detect the failure by noting 
at the R4 .RESPONS I BLE flag Is still set (and hence, that no triads are working 
on the R4 rate groups). This same check can be used to ensure that a new 
R4.TICK.TIME value has been entered. If the difference between R4. TICK. TINE and 
TIME. NOW at the end of the R4 task execution cycle Is less than zero (l.e. was 
not reset In the R4 Dispatcher), then the failure Is also detected. 
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TABLE 2.4 REQUIREMENTS FOR THE INTERVAL TIMER ACCEPTANCE TEST 

1. The Interval Timer Acceptance Test shall be Invoked after each of the 
following routines Is called: 

H0LD.R3.R1 .TIMERS 
H0LD.R1 .TIMERS 
RELEASE. R3.R1 .TIMERS 
RELEASE. R1 .TIMER 
START. R4. TIMER 
START. R3. TIMER 
START. R1 .TIMER 
ST0P.R4.TI*€R 
STOP. R3. TIMER 
ST0P.R1 .TIMER 

2. If the triad Is not R4. RESPONSIBLE, and the R4 dispatcher Is not active, 
the acceptance test will return control to the calling routine. 

3. If the R4 dispatcher Is active, the acceptance test will compare the 
value of the Interval time with the maximum permissible R4 limit. If 
the value of the limit Is exceeded, the acceptance test will Invoke 
the alternate dispatcher. 

4. If the triad Is R4.RESP0NS IBLE, the acceptance test will Invoke the 
alternate dispatcher If either of the following conditions Is met: 

a. R4. TICK. TIME - TIME. NOW < INTERVAL. TIMER 

b. R4, TICK. TIME - TIME. NOW < 0 

5 If neither of the conditions of (4) are met, then the acceptance test 
will perform a normal exit and return control to the calling routine. 
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FIGURE 2*7* Interval Timer Acceptance Test 






2.3. INPUT/OUTPUT ACCEPTANCE TESTS 


In addition to the acceptance tests dealing with execution of the dispatcher, 
the Input /out put routines must also be tested. The test criterion Is the number 
of times that a data buffer Is accessed In a given time period, and this Is 
compared with the frame count appropriately adjusted for even and odd frames as 
defined In the requirements shown In table 2.5. 

Because the I/O procedures for the MIL-STD 1553 bus were not within the scope of 
this work, no specific recommendations will be made. However, some general 
comments on the nature of the test are described here. 

The I/O acceptance tests verify that the dispatcher has invoked the Input/output 
routines In the proper sequence, and that the upcoming values which are used by 
the applications tasks are reasonable relative to those which had been used In 
the previous cycle. As currently conceived, the dispatcher reads In the data 
for all rate groups to be executed In a given frame during the R4 frame 
Initiation from a buffer location to which data as constantly being transmitted. 
The procedures performing this task, RX.INO and RX.OUTO, are executed as part 
of the R4 dispatcher. 

There are two major acceptance tests: (1) a test Invoked by the dispatcher to 
determine that the buffers of each of the data group have been accessed at the 
appropriate rates (Including an even/odd test), and (2) a test for the 
reasonableness of each data point, l.e. that the point varies In a reasonable 
way from (e.g. Is It within a certain range of) the previous point. 

In order to verify that the data group access counters have been checked, the 
I/O acceptance test must be an R4 critical task (whose execution Is noted In the 
critical word). The requirements for this acceptance test are given In table 
2.5. 
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TABLE 2.5. I/O ACCEPTANCE TEST REQUIREMENTS 


1. The number of times that a data group has been accessed will be 
compared with the frame counts. 

a. Data groups associated with R4 tasks will have counters that will 
be compared with R. FRAME. (RG4) . 

If the data group counter equals R.FRAME.(RG4), then the counter 
will be I ncremented . 

If the data group counter Is greater than 15, then the counter 
will be reset (to modulo 16) prior to being compared with the 
R. FRAME. (RG4) variable. 

If the data group counter does not equal R.FRAME.(RG4), the 
alternate dispatcher will be called. 


b. Data groups associated with R3 tasks will have counters that will 
be compared with R. FRAME ( RG3 ) . 

If the data group counter equals R. FRAME (RG3), then the counter 
will be Incremented. 

If the data group counter Is greater than 8, then the counter 
will be reset (to modulo 8) prior to being compared with 
R.FRAME(RG3) . 

If the data group counter does not equal R.FRAME(RG3), then the 
alternate dispatcher will be called. 

c. Data groups associated with R1 tasks will have counters that will 
be compared with R. FRAME ( RG1 ) . 

If the data group counter equals R.FRAME(RG1 ), then the counter 
will be Incremented. 

If the data group counter Is greater than 2, then the counter will 
be reset (to modulo 2) prior to being compared with R.FRAME(RG1 ) . 

If the data group counter does not equal R.FRAME(RG1 ), then the 
alternate dispatcher will be called. 


2. Within each applications task, a data acceptance test will determine 
whether the Input Is reasonable (I.e. Is within an acceptable range of 
the previous value). 

a. If the data Is not reasonable, the alternate applications task will be 
I nvoked 


41 


SB 

b. If the data Is not reasonable, then the applications task will use a 
backup data module. 


(the use of either alternative may be dependent on the specific nature of 
each applications task, flight conditions, and general practicality) 

3. Each rate group will have an acceptance test to ensure that the 
appropriate (even or odd) buffer Is being accessed* 

4. The I/O acceptance tests will be R4 critical tasks. 
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2.4. APPLICATIONS ROUTINES 


It Is assumed that each of the applications routines will have Its own 
acceptance test to verify correct execution. However, In addition to testing 
for the validity of output, these acceptance tests will perform two additional 
tests on the operation of the dispatcher: that constraints have been met and 

that the critical word bit has been set for this routine. 

The setting of critical word bits will occur at the beginning of each 
applications routine, and a function of the applications task acceptance test Is 
to ensure the appropriate value of the critical word at the conclusion of task 
execution. 

Testing for the violation of constraints Is most efficiently handled on the 
applications task level as part of the check for the validity of Input. 
However, failure to meet constraints Is a dispatcher fault and should result In 
Invocation of the alternate dispatcher If such a failure has critical 
Implications. Thus, In the event that constraints have not been met, the 
applications routine will reset Its bit In the critical word to Indicate that It 
has net run. When the dispatcher functional acceptance tests are run, they will 
detect failure to execute a critical task, and will Invoke the alternate 
d I spatcher . 
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SECTION 3 - STRUCTURAL ACCEPTANCE TESTS 


Structural acceptance tests check sections of code to ensure that key varia- 
bles have been set and functions have been executed. In section 1, the 
coverage of these tests is shown to be particularly important. Specific 
applications of structural acceptance tests are described for the following 
modules or subfunctions of the dispatcher: 

SLIP and R.DONE - Because the functional acceptance test requires both 
variables as criteria for deciding whether to read the critical word, errors 
In these variables as well as errors In the critical word will not be 
covered without assurance of the correctness of these Inputs. Two 
acceptance tests described In section 3.1 detect these failures. 

STUCK IN R4 FRAME - This condition can lead to the delaying of the next R4 
frame Initiation to such an extent that critical tasks will not be executed 
at their design rates. Failure to complete the current R4 frame In timely 
manner Is detected by the acceptance test described In section 3.2. 

KICK - If an R4. RESPONSIBLE triad retires without designating another triad 
to restart the new frame, then the entire task scheduling and dispatching 
function will be lost with no Indication of failure by the acceptance tests, 
which will not have been Invoked. An acceptance test verifying that KICK 
has been successfully executed Is described In section 3.3. 

R4. RESPONSIBLE - A related task Is the ensuring that one and only one triad 
Is R4.RESP0NS IBLE. Failure of the R4. RESPONSIBLE triad to Invoke the new 
frame will be detected by the Interval Timer acceptance test described In 
section 3.4. 

UNINTERRUPTIBLE CODE - Sections of uninterruptible ASM code In the FTMP 
operating system may lead to Infinite loops which would ultimately result In 
failure to restart the R4 frame If executed by the R4.RESP0NS I BLE triad. 
The uninterruptible code acceptance test described In section 3.5 covers 
this error. 

RET I REMENT - Failure of a triad to properly respond to a retirement command 
can result In a pathological condition with severe system consequences. 
This condition will be detected by the retirement acceptance test described 
In section 3.6. 
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3.1. ERRORS IN SLIP AND R.DONE 


;i'i jure T s ( ,n the setti ^ «„ 

necessary In order to ensure that the!l + ^ 0 h? +rUC+Ural acce P +ance tests are 
detect the following failures! variables are properly set. They must 

iz'°Ll he ', tera+ '°;r w,th ' n • 

finishes t t^lask ” I Ts+ [ a 1 1 ure of a rate 9 r ° u P +° be marked as complete as It 
execution'wl I'^bV detected b^SInctTlal^c^ 


3.1.1. Maximum Absolute Value for SLIP 


3 h .'| S , + c^are°s Se sL r rp U ^r: t t.m?J “IT* ar ? ShOW " tabla 3 -' a "« ♦ tgure 

rate for each flight i? f f? t a+ the ma * ll " um tolerable schedule slippage 

value lr?oS l^dlspalciler Ihtin ;,^'^^ V H !I! SLIP ’ la a «'8& • 

assoc I ate^ acceptance lest ^ by appl,C! ' t, °" s rout.ne .hlch has 


an 


more frequent than allowed for hv mimci id +? Vl STa f th 5 decre mentlng Is 

« ?e d r u , 

preferable to "the^ Invocation 0 of ^ the Alternate dispatcher !° W6r rat * 9r °“ PP '* 


3.1.2. RX.DONE not set to TRUE when task list execution completed 


the the array CONTROL lo^atloi 0 + J?th the g r ° u P +ask lls+ » contained In 

group, contained In CONTROL??) ' TJ + h l ° +aS L + ° be execu+ed by the rate 

previous Iteration has been completed and R DON^f^thtT' + + ,mplIes +ha+ +he 
set to tpiif i< ik F, ® Te v ana K#D0NE * or +nis rate group should be 

“Is L™ ; n cl tLl'arTslrin lab f1 t f er '* ' nwtod - The Wreme°„“ts £ 

Is shown In figure 3.2. 3 * 2, and +he corres P° nd 1 n 9 N-S diagram 
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TABLE 3.1. Requirements for the SLIP Acceptance Test 


The SLIP value acceptance test Is Invoked by the R4 dispatcher at 
the beginning of each frame. 

The absolute value of SLIP Is compared to Its maximum limit. If 
exceeded, the alternate dispatcher Is Invoked. 

If SLIP Is greater than zero, the alternate dispatcher Is Invoked. 

The value of MINSLIP is set as part of the initialization section of the 
R4 dispatcher. It is altered at the appropriate flight mode changes by a 
critical applications routine with an associated acceptance test. 


TABLE 3.2. Requirements for the RX.DONE Acceptance Test 


The RX.DONE acceptance test Is Invoked by the R4 dispatcher at the 
beginning of each frame. 

The values of the two elements In the array CONTROL of the lower rate 
group PCB’S are compared. The first element Is the pointer to the 
first applications routine of the lower rate group, and the second 
element Is the pointer to the next task to be executed when the 
dispatcher Is called. 

If the value in CONTROL(l) is null, and the RX.DONE variable for that rate 
group is FALSE, the alternate dispatcher is invoked. 



FIGURE 3.1. SLIP Acceptance Test 



FIGURE 3.2. R.DONE Acceptance Test 
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3.2. STUCK IN R4 ACCEPTANCE TEST 


Acceptance tests described In this section and In section 2 serve to ensure that 
the R4 dispatcher will be re-entered at the start of a new frame under all 
circumstances. However, If the R4 tasks are being dispatched late or some other 
disorder exists within the R4 dispatcher, then no error condition will be 
detected. The purpose of the STUCK IN R4 acceptance test Is to ensure that If 
there Is a delay In the dispatching of the R4 tasks, the delay Is within some 
previously defined acceptable limits. 

Requirements for the test are shown in table 3.3, and figure 3.3 is the 
corresponding N-S diagram. The test uses an applications routine selection 
counter, R4.APP. COUNTER, which Is Initialized at the beginning of each R4 frame 
and Is Incremented Immediately after the successful selection of an R4 
applications task. The expected completion time for the R4 frame Is determined 
by the difference between TIME. NOW and R4. TICK. TIME, the time at which the 
present R4 frame was started. If this difference Is greater than R4. PERIOD, 
then R4.APP. COUNTER Is compared to a limit denoted as R4.LATE.LIM, which Is the 
minimum number of tasks expected to be executed by the end of the frame. If 
R4.APP. COUNTER Is less than R4.LATE.L IM, the alternate dispatcher Is Invoked. 

R4.LATE.LIM can be dynamically changed during subsequent cycles of the R4 task 
selection and dispatching by means of a linear (or other function) In order to 
ensure that satisfactory progress Is made on completion of the R4 Iteration 
after the expected completion time. The merits of monitoring progress must be 
weighed against the disadvantages In Invoking the alternate dispatcher when the 
situation Is not sufficiently critical to warrant such action. 
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Table 3.3. Requirements for the STUCK IN R4 acceptance test 


1. The STUCK IN R4 acceptance test will be Invoked after the execution of 
procedure SELECT. TASK. 

2. An R4 applications routine counter, R4.APP. COUNTER, will be Initialized 
at the start of each R4 frame. After the successful selection of a task, 
R4.APP. COUNTER will be Incremented. 

3. If a task has been successfully selected, the acceptance test will check 
the difference between the current time, TIME. NOW, and the time since the 
R4 dispatcher was re-started (R4. TICK. TIME) . 

a. If this difference Is less than R4. PERIOD, the acceptance test will 
exit without further executable statements. 

b. If this difference Is greater than R4. PERIOD, R4.APP. COUNTER will be 
compared with R4.LATE.LIM. If R4.APP. COUNTER Is less than R4.LATE.LIM, 
the alternate dispatcher will be Invoked. 

4. R4.LATE.LIM may be changed dynamically If monitoring the progress of the 
applications task following the expected end of the frame Is critical. 
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TIME. NOW - R4 .TICK .TIME > R4 .PERIOD AND^^ 
R4.APP. COUNT < R4.LATE.LIM^-"^ 

YES 

NO 

INVOKE ALTERNATE DISPATCHER 

ADJUST LATE LIMIT 
(AS NECESSARY) 


FIGURE 3.3. STUCK. IN.R4 Acceptance Test 



FIGURE 3.4. KICK Acceptance Test 
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3.3. 


KICK ACCEPTANCE TEST AND MODIFICATIONS TO KICK PROCEDURES 
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Table 3.4. Requirements for the KICK Acceptance Test 


1. The KICK acceptance test will be executed Immediately after the KICK 
of the R4 dispatcher as a result of retlrment occurs. 


2 . 


The acceptance test will read TR TAD. BUSY ( RG4 ) , and compare It to the 
value of TRIAD. ID of the calling triad. If the value of TR I AD . BUSY ( RG4 ) 
Is less or equal to TRIAD. ID, then the alternate dispatcher will occur. 


3. This acceptance test will not be executed when KICK Is used to transfer 
the R4 dispatcher to another triad under other circumstances. 
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3.4. R4. RESPONSIBLE ACCEPTANCE TEST 


The purpose of this acceptance test Is to ensure that the R4.RESP0NS IBLE flag 
has been set In at least one triad before the conclusion of the execution of the 
R4 dispatcher. The N-S diagram and procedure requirements are given In figure 
3.5 and table 3.5 respectively. The test first ensures that the value of 

TRIAD .COUNTER , the variable used to determine what triad will be responsible for 
starting the next frame, is within the expected range (0 to 2). If no other 
triads are executing the R4 dispatcher, this procedure checks that both 
R4. RESPONSIBLE is TRUE and that the difference between the current time 
(TIME. NOW) and the time to the beginning of the next frame (R4. TICK. TIME) is no 
more than the R4 frame length (R4. PERIOD). 

If another processor triad Is still executing the R4 dispatcher, then two or 
more triads would be R4. RESPONSIBLE, a condition which could result In a number 
of adverse consequences upon the restart of the R4 dispatcher. It Is for this 
reason that this acceptance test will Invoke the alternate dispatcher If 
TRIAD. COUNTER Is not zero when R4.RESP0NS IBLE Is TRUE. 



Table 3.5. Requirements for the R4. RESPONSIBLE Acceptance Test 


1. The test Is Invoked by the R4 dispatcher Immediately before the RESUME (0) 
statement. 

2. The test will Invoke the alternate dispatcher If any of the following 
conditions are mets 

(a) TRIAD. COUNTER < 0 or TRIAD. COUNTER > 2 

(b) TRIAD. COUNTER * 0 AND R4. RESPONSIBLE = FALSE 

(c) R4. TIME. TICK - TIME. NOW > R4. PERIOD 

(d) TRIAD. COUNTER >= 1 AND R4. RESPONSIBLE * TRUE 
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TRIAD. COUNTER <0 OR >2? 
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FIGURE 3.5. R4. RESPONSIBLE Acceptance Test 







3.5. UNINTERRUPTIBLE CODE ACCEPTANCE TEST 


Appendix B lists the series of assembly language routines which are called by 
the dispatcher or associated routines and which have sections of uninterruptible 
code. As Is shown In table B-2, six of these routines have conditional branches 
or loops within them, and the possibility of an Infinite loop due to a software 
logic, environment, or execution error exists. If the R4.RESP0NS IBLE triad Is 
Invovled, the R4 Interrupt will not be acted upon. 

The remainder of the system can be in one of six configurations under this 
condition: 

1. Two other triads idling. 

2. Two other triads working on other applications routines. 

3. One other triad working, one retired. 

4. One other triad idling, one retired. 

5. Both triads retired. 

6. One triad working and one idle. 

With the exception of 5, these configurations may be grouped Into the following 
( non-mutua 1 1 y exclusive) categories: 

( I ) At I east one tr I ad work I ng . 

(II) At least one triad In the Idle process 

The two acceptance tests described below are to be run under the applicable 
conditions. 


3.5.1. At least one triad working 

If at feast one other triad Is performing a task. It will eventually be 
interrupted or will go to an Idle state. If the triad receives a timer 
Interrupt, control will pass to the timer Interrupt handler. The acceptance 
test whose requirements are described In table 3.6 and depicted In the N-S 
diagram of figure 3.6 Is appended at the end of the timer Interrupt handler, and 
will evaluate whether the R4 dispatcher should be restarted. If not, this triad 
Invokes the alternate dispatcher. 

There are two conditions which will cause Invocation of the alternate dispatcher 
under these conditions: 

(a) If there Is still an R4 .RESPONSIBLE triad (l.e. the R4 dispatcher has 
not been restarted) at the expected restart time plus an allowance DELTA, 
then the alternate dispatcher will be Invoked; 

(b) If there are no triads running the R4 dispatcher beyond the allowed 
time, the alternate dispatcher will be Invoked. 
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3.5.2 At least one triad In the Idle process. 

All triads In the Idle mode will subtract the current time (TIME. NOW) from the 
time to the new R4 frame (R4. TICK. TIME) . If the difference exceeds the expected 
time for the R4 dispatcher to Invoke the KICK routine to start up other triads 
(denoted as DELTA. KICK) and other triads are available for running the R4 
dispatcher, the Idling triad will Invoke the alternate dispatcher. 

The Idle mode acceptance test provides coverage for the following two situations 
(1) when the R4 dispatcher Is stuck In an uninterruptible Infinite loop after 
restarting the current frame or (2) when the last triad leaving the R4 
dispatcher Is stuck prior to designating Itself as R4.RESP0NS IBLE. The reader 
should note that the STUCK IN R4 acceptance test provides coverage In the event 
that the dispatcher Is unduly delayed, but not under this condition. 
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TABLE 3.6. Requirements for the Uninterruptible Code Acceptance Test 

At Least One Triad Is Working 


1. The Uninterruptible Code acceptance test will be Invoked at the 
beginning of the TIMER. INTERRUPT. HANDLER routine. 

2. A constant DELTA defined as expected time to enter the R4 dispatcher 
and set R4.RESP0NS IBLE to FALSE will be defined during system 
Initial Izatlon. 

3. The test will read R4. TICK. TIME and TIME. NOW. If TIME. NOW - 

(R4. TICK. TIME + DELTA) Is less than or equal to zero, a normal return 
will be effected. 

4. If TIME. NOW - (R4. TICK. TIME + DELTA) Is greater than zero and the triad 
Is R4. RES PONS IBLE, the test will determine the contents of the APSD. 

a. If the APSD = R4.PSD, a normal return will occur. 

b. If the APSD Is any other quantity, the alternate dispatcher 
will be Invoked. 

5. IF TIME. NOW - (R4.TICK.TI ME + DELTA) Is greater than zero and the triad Is 
not R4. RESPONSIBLE, the test will check the TRIAD. COUNTER (l.e. the 
number of triads executing the R4 dispatcher). 

a. The triad will determine whether any other triad Is R4. RESPONSIBLE. 

If no other triad Is R4. RES PONS IBLE and the TRIAD. COUNTER Is greater 
than or equal to 1, then a normal exit will occur. 

b. If another triad Is designated as R4. RES PONS IBLE beyond this time 
limit, the alternate dispatcher will be Invoked. 

c. If the TRIAD. COUNTER Is zero, the alternate dispatcher will be Invoked. 
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FIGURE 3.6. Uninterruptible Code Acceptance Tests Triad Working 


TABLE 3.7. Requirements for the Uninterruptible Code Acceptance Test - 
At Least One Triad Is In the Idle Process 


1. This test will be executed constantly when the triad Is In the Idle 
process. 

2. The triad will determine the difference between TIME. NOW and R4. TICK. TIME. 

a. If this difference Is less than DELTA. KICK, the expected time to 
execute the KICK Instruction to restart another triad, 

a normal return will occur. 

b. If this difference Is greater than DELTA. KICK the test will determine 
the number of triads available to execute the R4 dispatcher (by means 
of the TRIAD.STATUS(RG4) array) and the number executing the R4 
dispatcher (by means of the TRIAD. COUNTER variable). If this 
difference Is greater than zero, the test will Invoke the alternate 
dispatcher. 



FIGURE 3.7. Uninterruptible Code Acceptance Test: Triad Idling 



3.6. RETIREMENT ACCEPTANCE TEST 


Prior to execution of Its task list, the R4 dispatcher executes the 
configuration program which generates commands for retirement of faulty triads. 
The actual setting of control variables and the command to retire Is performed 
by the R4 dispatcher Itself, however, and this function Is covered by the 
Retirement acceptance test. 

Should a triad be commanded to retire, the dispatcher will zero appropriate bits 
In the TRIAD. BUSY and TRIAD. STATUS arrays, pass the responsibility for the R4 
frame restart to another triad If the retired one Is R4. RESPONSIBLE, and exit 
the R4 dispatcher. The Retirement acceptance test checks the TRIAD.CMND and 
TRIAD. STATUS words of all triads to ensure that a faulty triad has both 
sucessfu I ly retired and properly executed Its acceptance test. 

The Retirement acceptance test is executed immediately prior to the RESUME (0) 
statement at the conclusion of the R4 dispatcher. If no retirement commands 
have been issued, the acceptance test is exited. However, if the configuration 
task issues a retirement command to the triad, the acceptance test checks the 
TRIAD. STATUS bits for the triad. If they are set to FALSE, the retirement 
directive has been successfully executed and the test will take a normal exit. 
However, if this bit is TRUE, the acceptance test will test for a previous 
failure. If no previous failures of this kind have occurred, the acceptance 
test will set a failure indicator and set the TRIAD .STATUS word. Any subsequent 
retirement failures would terminate execution of the primary dispatcher. 
Table 3.8 and figure 3.8 show the requirements and N-S diagram for the 
Retirement acceptance test. 
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TABLE 3.8. Requirements for the Retirement Acceptance Test 


1. The Retirement acceptance test will be Invoked Immediately prior to the 
RESU>C(0) statement concluding execution of the R4 dispatcher. 

2. The acceptance test will read the TRIAD. CMND word from main memory. If 
the command does not Indicate retirement, the test will exit. 

3. If the TRIAD. OUD Is GO. TO. IDLE for of any processor, the acceptance 
test will read the TRIAD. STATUS word. 

4. If the TRIAD.STATUS(RG4) Is FALSE, the acceptance test exits normal ly. 

5. If TR I AD. STATUS (RG4) Is TRUE, the acceptance test checks a failure In- 
dicator designated as RET.FAIL. 

a. If RET.FAIL Is FALSE, the acceptance test sets It to TRUE, and sets 
the TRIAD. STATUS to FALSE. 

b. If RET.FAIL Is TRUE, the test Invokes the alternate dispatcher. 

c. RET.FAIL Is set to FALSE as part of system Initialization. 
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I AD CONWAND 3 GO. TO. IDLE? 
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FIGURE 3.8. Retirement Acceptance Test 






-SECTION 4 - ALTERNATE D I SPATCHFR 


This section covers the requirements and design of the alternate dispatcher 
as well as the conditions under which It returns control to the operating 
system. The dispatcher requirements are based on refs. 4 and 5. The design 
of the alternate dispatcher Is Intended (1) to be as simple as possible 
while fulfilling the necessary requirements and (2) to be Independent of the 
primary dispatcher. 


4.1. ALTERNATE DISPATCHER REQUIREMENTS 

The alternate dispatcher performs the following functions 

1. Initialization of system configuration variables. 

2. Identification of lead, support, and Inactive triads 

3. Sequencing and Dispatching of I/O. 

4. Dispatching of applications routines In a predetermined order. 

5. Identifying conditions for return to the primary dispatcher. 

6. Acceptance tests and aborts 


Startup -Initial Izatlon of the alternate dispatcher 

Because the system will already be under "warm start" conditions at the time the 
alternate dispatcher Is Invoked, relatively little Initialization will be 
performed by the alternate dispatcher. It Is anticipated that other systems 
software, e.g. the configuration controller, reading and setting of error 
latches, the I PC Interrupt routines, and supporting ASM routines, will not be 
affected by a dispatcher failure. Startup Initialization Includes the 
fol lowing: 


alternate dispatcher task list 

setting the alternate execution counter and repetition limit 
Informing other triads of the Invocation of the alternate dispatcher 
saving the state of the triads, busses, and memories 

ldsni.lf 1 cat I on of Jead and support triads 

The only assumption on the number of operational processors made In the design 
of the alternate dispatcher Is that at least one triad will be functional. This 
triad will be responsible for calling the critical tasks of all rate groups In 
the appropriate sequence. Non-Crltlcal tasks from all rate groups will run on a 
second triad If available. Other operational processors will be designated as 
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spares . 


The triad Invoking the alternate dispatcher will designate Itself as lead triad, 
and will Invoke the IPC Interrupt routine to Inform other triads of the 
dispatcher change. The first triad responding will be designated support triad? 
remaining processors will be spares. The lead triad will continue to run the 
alternate dispatcher; the support triad will run all non-crltlcal applications 
routines In a fixed order. 

Sequencing and dispatching of l /fi 

The total responsibility for the reading and writing of I/O buffers to the 
MIL-STD-1553 bus will rest with the first critical applications routine to be 
run on the R4 Iteration group. This routine will have responsibility for 
designating even and odd buffer storage areas and performing the appropriate 
updating and sampling as required by the applications routines. In the absence 
of detailed specifications of the Ml L—STD”1 553 protocols and applications 
routines developed for the FTMP, no further detailed requirements will be 
specified. 

Sequencing and Dispatc h ing of appl I cat Ions. JPJitlncs 

Because only a single triad will be used to dispatch the critical task list and 
a second triad will be used to Implement an Independent set of non - critical 
tasks, the following features which were a necessary part of the primary 
dispatcher were eliminated In the Interest of simplicity and Independence for 
the alternate dispatcher: 

(1) the recognition of constraints for applications routines 

(2) the starting of new frames at fixed time Intervals 

(3) LOCK and UNLOCK functions for memory locations 

The fact that features (1) and (3) are not implemented Is Inconsequential when 
only one triad Invokes all applications routines. The loss of feature (2) 
Implies that that It Is no longer correct to speak of a rate group or frames. 
Thus, In the alternate dispatcher, rate group Is replaced with "Iteration group" 
and frame Is replaced with "Iteration", l.e. R3 Iteration group. Iteration 
count, etc. 

The alternate dispatcher will maintain the execution order of the primary 
routine by means of a task list which Is placed Into cache memory as part of the 
Initialization process. The task list Is divided Into three Iteration groups 
similar to the rate groups of the primary routine. The R4 Iteration group, 
placed at the beginning of the list. Is executed first. The R3 Iteration group 
Is executed every second Iteration, and the R1 group Is executed every eighth 
Iteration. 

Acceptance Test and Restarting of the Prima ry PlSPfltChfiE 

At the conclusion of each Iteration, the alternate dispatcher will run Its 
acceptance test, and. If passed, will Increment an execution counter and 
re- Invoke the primary dispatcher If the execution limit has been reached. If 
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the alternate dispatcher falls, an alternate failure flag will be set, and 
control passed to another triad. If the routine falls a second time, then the 
processor will enter an abort routine. 
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4.2. DESCRIPTION OF THE ALTERNATE DISPATCHER 


Flq Ur e 4.1 Is an N-S diagram of the alternate dispatcher. When It Is first 
Invoked, this routine engages In the Initialization and startup activities 
described above. It then enters the task execution loop In which the critical 
words are reset, the Iteration count Incremented, and the tasks from the various 
rate groups are run. At the conclusion of an Iteration, the alternate 
dispatcher acceptance test (similar to that of the primary dispatcher) Is run. 


In order to achieve a further degree of Independence, the alternate d * s Pa+cher 
calls the applications routines rather than "stringing" them by means of the PSD 
scheme used In the primary. Prior to the calling of applications routines, the 
Interval timer Is set using the START. R4. TIMER procedure (for all ^ration 
groups). For the sake of simplicity and reliability, a single time will be used 
In this routine rather than reading a time limit from the task control block. 
If a timer Interrupt occurs, control Is passed back to the dispatcher which then 
calls the next task. In addition to not providing for the checking of 
constraints as noted above, the alternate dispatcher has no provisions for 
checking on the task return code or frame count. As was the case In the primary 
dispatcher, applications routines are expected to set a bit In the appropriate 
Iteration group critical word and to contain Internal recovery blocks. 


The first failure to complete all critical tasks In an Iteration will cause the 
dispatcher to be transferred to the support triad and the suspension of 
execution of non-crltlcal tasks. If the failure persists, execution of the 
alternate dispatcher ceases and the system enters the abort routine. 


Because of the limited capabilities of the alternate dispatcher. It Is desirable 
to return to the primary routine as soon as possible. As a result, a repetition 
limit, based on the number of previous failures of the primary routine. Is set 
during the startup Initialization. When the dispatcher completes an Iteration, 
It Increments an alternate execution counter which Is then compared to the 
repetition limit. Once the limit Is reached, control Is passed back to the 
primary procedure and the system restored to Its original state (unless hardware 
failures have occurred In the Intervening time). As was the case prior to 
Invocation of the alternate dispatcher, acceptance tests w 1 1 1 cont I nue to 
monitor all aspects of the operation of the dispatcher and Invoke the alternate 


once again upon detection of any failures. 
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F I GURE 4.1. A I ternate D 1 spatcher 
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AEPENDIX A - NEW VARIARirs fiEgiLLBEQ 


VAR. NAME 

ROUTINE 

PURPOSE 

MINSLIP 

SLIP ACCEP. 
TEST 

maximum absolute value SLIP can have prior 
to the Invocation of the alternate dispatcher 

MAX.R4.TIME 

INTERVAL 
TIMER ACCEP. 
TEST 

Maximum value that can be loaded Into an R4 
timer (l.e. maximum execution time for an 
applications routine) 

R1.CRIT.WD 

DISPATCHER 
ACCEP. TEST 

Indicator that R1 critical tasks have been 
dispatched 

R3.CRIT.WD 

DISPATCHER 
ACCEP. TEST 

Indicator that R3 critical tasks have been 
dispatched. 

R4.CRIT.WD 

DISPATCHER 
ACCEP. TEST 

Indicator that R4 critical tasks have been 
dispatched. 

RX.INIT.CRIT 

CRITICAL WORD 
RESET ACCEP. 
TEST 

Initial values of critical words 

OLD. FRAME, 
NEW. FRAME 

FRAME COUNT 
ACCEP. TEST 

Lead and lag counters to ensure that frane 
counter Is appropriately Incremented 

FRAME. FAIL 

FRAME COUNT 
ACCEP. TEST 

Counter for number of errors In Incre- 
menting frame count 

R4.APP. COUNT 

STUCK IN R4 
ACCEP. TEST 

Counter of dispatched R4 tasks 

ALT. EXEC. COUNT 

ALTERNATE 

DISPATCHER 

Counts executions of alternate dispatcher. 

REP. LIMIT 

ALTERNATE 

DISPATCHER 

Repetition limit for alternate dispatcher 
after which primary Is re- Invoked. 

PRIM. FAIL. COUNT 

ALTERNATE 

DISPATCHER 

Counts primary dispatcher failures. 

PREV. ALT. FAIL 

ALTERNATE 

DISPATCHER 

Indicator of previous alternate dispatcher 
failure 

TASK. LIST 

ALTERNATE 

DISPATCHER 

Array of task Identifications for alternate 
dispatcher. 
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VAR. NAKE 
DELTA 

DELTA. KICK 


ROUTINE PURPOSE 


UN INTERRUPT. Time after new frame start for R4.RESP flag 

COOE ACCEP. +o be set to FALSE 

TEST 


UN INTERRUPT. 
CODE ACCEP. 
TEST 


Time after new frame start for Idling triad 
to start the R4 dispatcher. If It Is not R4 
responsible 
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AEPENDJX B - UNINTERRUPTIBLE ASM ROUT INFS 


Because failure detection by the proposed acceptance tests Is contingent upon 
the Implementation of the R4 Interrupt, sections of code In which this Interrupt 
Is disabled are of significance. Failure to exit from these routines would 
result In Inhibition of the R4 rate group restart, and a major but undetected 
failure would result If the "hung up" triad Is R4 responsible. 

ASM routines called by the AED rate group dispatchers and associated procedures 
were checked for the presence of a SWAPMSK command that would disable all (and 
hence R4) Interrupts. The following procedures were examined: 

DISP.R4 

DISP.R3.R1 

SELECT. TASK 

EXECUTE 

HOLD. TIMER 

RELEASE. TIMER 

READ. EL 

SET. BIT 

KICK 

LOCK 

UNLOCK 


Table B.1 shows the list of ASM routines In these procedures, and an Indication 
of whether all Interrupts are disabled. Table B.2 shows the eight ASM routines 
which disabled Interrupts, their function, and notes on the complexity of the 
code during the Interrupt defeat. 

Software failures In routines with straight-line code or with a limited number 
of unconditional Jumps are unlikely. However, when loops or conditional Jumps 
are present, the possibilities of failure Increases. Based on Table B.2, It Is 
possible to rule out HOG. BUS and possibly RELEASE. BUS as sources of concern. 
However, for the remainder of the ASM routines. It Is necessary to determine 
whether the R4 Interrupt should be enabled, whether other means exist to detect 
the R4 Interrupt, or whether additional measures (which will increase the 
complexity of the operating system) are appropriate. 
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Table B.1 


AED Procedures and Associated ASM Routines 


AED Procedure ASM Routine Unlnterruptable Code 


DISP4 

READ 

YES 


WRITE 

YES 


PEND 

YES 


RESUME 

YES 


SWAPMASK 

NO 

SELECT. TASK 

READ 

YES 


WRITE 

YES 


SWAPMASK 

NO 

EXECUTE 

READ 

YES 


WRITE 

YES 


ACTIVATE 

YES 


ASNBIT 

NO 

HOLD.TIMER 

SWAPMASK 

NO 

RELEASE TIMER 

SWAPMASK 

NO 


WRITE 

YES 

TIMER. 1 NT. HANDLER 

PEND 

YES 


RESUME 

YES 

READ. EL 

READ 

YES 


HWRITE 

YES 


WRITE 

YES 

SET.BIT 

HOG. BUS 

YES 


ASNBIT 

NO 


WRITE 

YES 


RELEASE. BUS 

YES 

CLEAR. T. EL 

SREAD 

YES 

KICK 

HOG. BUS 

YES 


READ 

YES 


HWRITE 

YES 


RELEASE. BUS 

YES 

LOCK 

HOG. BUS 

YES 


READ 

YES 


WRITE 

YES 


RELEASE. BUS 

YES 


SWAPMASK 

NO 
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Table B.1 (continued) 

AED Procedures and Associated ASM Routines 


AED Procedure ASM Routine Unlnterruptable Code 

unlock SWAPMASK no 

HOG. BUS YES 

READ YES 

ASNBIT NO 

WRITE YES 

HWRITE YES 

RELEASE. BUS YES 
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Table B.2 



ASM Routines Containing Uninterruptible Sections of Code 

ASM Routine 

Called By 

Descr I pt 1 on 

Note 

READ 

DISPATCHERS 

Reads from main 



SELECT. TASK 

EXECUTE 

READ. EL 

KICK 

LOCK 

UNLOCK 

memory; Interrupt 
Inhibited while 
data Is transferred. 

1 

WRITE 

DISPATCHERS 

Writes to main 



SELECT. TASK 
EXECUTE 
RELEASE. TIMER 
SET. BIT 
LOCK 
UNLOCK 

memory ; 1 nterrupt 
Inhibited while 
data Is transferred 

1 

ACTIVATE 

EXECUTE 

Store new PSD, mask 
string If necessary 

2 

PEND 

TIMER. 1 NT. HANDLER 

String new PSD behind 
current PSD 

3 

RESUME 

DISPATCHERS 
TIMER. 1 NT. HANDLER 

Resume previously 
Interrupted task 
(take old PSD and 
make current). 

4 

HWRITE 

READ. EL 

Write to hardware 
register. Inhibits 
Interrupt during 
hardware transfer. 

5 

HOG. BUS 

SET. BIT 

KICK 

LOCK 

Increment HOG. WORD 

6 

RELEASE. BUS 

SET. BIT 

KICK 

LOCK 

Decrement HOG. WORD 

7 
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flptes for Table B.2 


U eacl^transf er? EG ' ^ ' abe ' (Nne58> ,nh,bI+s Interrupt. Several Jumps In 

2. Part of KERNEL. 4 Jumps (2 conditional) In uninterruptible sequence. 

3. 1 loop, 1 conditional Jump, 17 Instructions In uninterruptible sequence. 

4 * k ™EL (not yet clear how entered). SWPMSK assumed prior to 

Interrupts $ s+a+emen+s ' 2 J um P s P r,or + ° SWPMSK which would re-enable 


5. Numerous conditional Jumps (depending on amount of data to be transferred) 
and ASM statements In uninterruptible execution sequence. 

6. 7 statements, no Jumps or loops. In uninterruptible sequence. 

8. 1 conditional Jump, 1 unconditional Jump, 22 statements In uninterruptible 
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